Diagnostic subsystems have, in the past, been applied in at least two different applications. In one application, diagnostic systems and sub-systems have been used as a part of the manufacturing process. More particularly, after a product is manufactured it is connected to a diagnostic system or sub-system to insure that the manufactured device meets manufacturing specifications and is in condition for sale. In an entirely different application, diagnostic sub-systems have been included as part of computer systems. Typically such an on board diagnostic sub-system is initiated into operation as part of Power On Reset (POR) sequence each time the computer system is powered up or reset. The diagnostic sub-system performs a routine of tests and either allows normal processing to be initiated if the tests are successfully passed or reports some information about any tests which are not successfully completed.
One problem faced by the diagnostic sub-system designer is typified by the expandable nature of the Personal Computer (PC). More particularly the nature and complement of devices included in the computer system cannot be predicted. This unpredictability limits the extent and nature of the diagnostics. Prior art I/O devices, for example hard files, are associated with a device controller, and the device controller is usually tested with the device connected to the controller. Prior art ST506 and Enhanced Small Device Interface (ESDI) devices are examples of this architecture.
More recently, with the advent of the SCSI standard, logic which is dedicated to operation of devices such as a hard file has been moved from the controller to the hard file assembly itself. This leaves a generic interface which actually operates as a low cost network and is capable of supporting hard files, diskette drives, CD ROM drives, printers etc. This new architecture requires a completely different method of testing the SCSI controller from those used in the ST506 and ESDI arrangements. See in this regard, "Solving the Test Problem in SCSI Disk Drives" appearing in Electronics, page 35 at seq., Feb. 17, 1986; Robinson, "SCSI Interface Demands New Test Methods", Mini-Micro Systems, page 35, April, 1988; Squires, "Outsmarting Smart Interfaces to Test Winchester Drives", Electronics Test, February, 1988; "Western Digital Slashes SCSI Bus Overhead Time" in Electronics, Aug. 20, 1987 and Aseo, "Disc Interfacing Gets Smart", ESD: The Electronics System Design Magazine, page 77, November 1987.
The SCSI or generic interface raises a number of testing issues especially with respect to the SCSI interface between a system, such as a Personal Computer system, and a plurality of devices coupled to the SCSI interface through a SCSI bus. Although in prior devices the hardware between a system and a peripherial device was identified as a controller this application will refer to the hardware interfacing the computer system and the SCSI devices as a SCSI adapter. Thus the SCSI adapter has a port coupled to a first bus which first bus is coupled to a port of the computer system. The SCSI adapter has a second port which is coupled to the SCSI bus and via that bus to one or more SCSI devices. Typically the SCSI adapter includes a SCSI controller as a component.
One problem raised by the SCSI interface is caused by the inability to assume a particular configuration of devices connected on the SCSI bus. Because no configuration can be assumed, it is not possible to select specific test procedures, for execution, based on the configuration. For example one configuration may require a collection of printers, another configuration may include a collection of read only CD ROMS, another configuration may have a plurality of read/write hard files, a different configuration may have all of the above and finally a further configuration may include devices still being developed. The inability to assume a particular device configuration, coupled with the limitations a particular device may provide in testing many of the modes of operation requires a new and effective test capability which is effectively independent of the devices connected on the SCSI bus.
A second problem is the necessity to isolate defects in the drivers and receivers in the SCSI adapter or more particularly, the SCSI controller contained in the adapter. Often if the drivers and receivers are defective, the defects cannot be isolated between the adapter, the cable or the device.
A third problem is the testing environment. The test sub-system may operate in an environment in which it is not the autonomous bus master, this is particularly true of the SCSI environment. While in the SCSI environment the adapter usually has the highest priority, nevertheless other devices may attain control of the bus and that condition must be respected; furthermore there may be more than a single adapter on the bus. As a result the diagnostic sub-system must take into account the presence of other devices which may be connected on the bus. If the diagnostic sub-system assumes control of the SCSI bus, it is conceivable that it can interfere with the operation of other bus users to the detriment of the entire system.